[レポート]ナビタイムジャパンの AWS コスト最適化の秘訣～Amazon EC2 フリート有効活用およびコスト最適化手法～ #AWSSummit

どーもsutoです。

2020年9月8日から9月30日の間でオンラインで開催されているAWS Summit Onlineの「ナビタイムジャパンの AWS コスト最適化の秘訣～Amazon EC2 フリート有効活用およびコスト最適化手法～」のセッションレポートです。

セッション情報

概要

ナビタイムジャパンでは、2017 年～2019 年度にかけて実施していたアプリケーションのバックエンドシステムのクラウド移行がまもなく完了する。オートスケール導入により耐障害性向上を図ることに成功したが、クラウド費用の抑制が次の課題に上がった。 本セッションでは、EC2 フリートとリザーブドインスタンスの活用による大幅なコスト削減事例およびコスト監視・全体コスト最適化について紹介する。

Speaker

株式会社ナビタイムジャパン ACTS インフラグループ

田中 一樹

株式会社ナビタイムジャパン ACTS インフラグループ マネージャー

小泉 亮輔

レポート

乗換NAVITIMEのシステム構成とコスト移行推移

• AWS移行直後にシステム改修や切り戻しが発生した（その期間はコスト効率が落ちた）
  • 継続的にコスト削減の対策を行わなければならないと考え、改善を実施してきた

• 成果
  • リクエスト120％増　→　コスト80％削減（リクエスト増に対するコスト増の割合）
  • →オンプレの頃と比較すると　→　コスト30％削減

どのようにコストカットしていったか

毎月の請求書をしっかりチェックし、以下のポイントをピックアップ

• EC2：オンデマンド起動が多い
  • RI購入、スポットインスタンス活用
  • ミックスインスタンスグループ活用
• EBS io1：性能を使いこなしてない
  • gp2へ移行（io1の利用停止）で、性能は容量確保で担保
• EBS容量：スケールアウト上限までの予備EBS準備（オートスケール高速用）
  • データ量の容量削減
  • データ圧縮方式変更（zstd）によりダウンロード処理高速化
• NATGateway：APIの外部通信費用
  • 同一ECSサービスへの複数ターゲットグループ登録を利用してint/extの分離
  • ↓参考

EC2費用削減の詳細

• スポットインスタンスで使えそうなもの
  • コンテナ系
• スポットインスタンスで使えなそうなもの
  • DB on EC2
  • コンバータ類
• 数年間、常時起動しておくようなものはRIを購入
• スケールアウトは「ミックスインスタンスグループ」
  • オンデマンド（＝リザーブド）とスポットを1つのAutoScalling Groupに

• 結果：オンデマンドの起動時間を90％削減、コストは30％以上削減
• RIの使用率95％を堅持
• オンデマンドOnlyの環境を比較して約50％安くEC2を使えた

その他の全体コスト削減について

• EC2で実装する必要のない処理は「API Gateway＋Lambda」を使い、クラウドネイティブに
  • 一部のレガシー資産部分では、パスベースルーティングでALB→直接Lambdaへ（APIサーバを介さずに）
• S3利用料金についての注意点
  • イベントフックでデータ整形し、prodフォルダに転送するところを、バケット全体に設定してしまうと無限リクエストになってしまった
  • S3ライフサイクル設定を徹底
• CloudWatchLogsの注意点
  • バグによる無限ログ出力＆転送を検知したい
  • →AWS Cost and Usage Reportを利用、S3転送＆Athenaで日時監視
• NAT Gatewayの料金をさらに下げたい（VPCエンドポイントを併用）
  • ゲートウェイエンドポイント：追加料金不要、NATGatewayの通信費を抑えられる
  • →（S3、Athena、DunamoDBなど）
  • インタフェースエンドポイント ：起動時間＋転送量課金がかかるので注意
  • →（API Gateway、CloudWatchLogs、Kinesis、ECRなど）

問題点

• リザーブドで購入したインスタンスタイプが起動しないことがある
  • 予定外のインスタンスタイプが起動してきたら通知、希望するインスタンスに置き換え
• スポットが確保できないこともある
  • （私の所感：これは仕様上しかたない）
• オンデマンドの割合はゼロにはできない
  • Scheduled Reserved Instancesが東京リージョンに対応してほしい
• Saving Planが使えない（今の運用が確立されすぎて）
  • 実際RIのほうが確実
• 複数AMIが指定できない
  • AutoScaling Group1つで複数AMI もしくは AMI1つでマルチアーキテクチャに対応可能にしてほしい

今後の展望

• API Call数の削減や通信量の削減をさらに実施予定
  • そのためのログやツールが潤沢になることを期待
• Amazon EC2の単価を見ながらコストパフォーマンスの高いインスタンスタ イプをこれからも積極採用

感想

考えなしで使っているととても大きな費用となるEC2に対し、徹底してコスト削減の施策を的確に実施していて素晴らしい内容でした。日本企業の間でEC2のコスト意識やRIの利用率がどんどん上がれば、Scheduled Reserved Instancesの東京リージョン対応が実現に近づくかもしれませんよね。

展望にあった、様々なインスタンスタイプの吟味をこれからも続けていくのであれば、EC2 Auto Scalingがインスタンスタイプ混在時の「インスタンスの重み付け」をサポートされましたので、この辺のオプションと組み合わせればよりコスパ良くインスタンスを使い倒せるようになるかもしれませんね。

セッションのリンク

• 動画リンク